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The Trajectory Synthesizer is a software program that generates aircraft predictions for 
Air Traffic Management decision support tools. The Trajectory Synthesizer being used by 
researchers at NASA Ames Research Center was restricted in the number of trajectory 
types that could be generated. This limitation was not sufficient to support the rapidly 
changing Air Traffic Management research requirements. The Generalized Profile 
Interface was developed to address this issue. It provides a flexible approach to describe the 
constraints applied to trajectory generation and may provide a method for interoperability 
between trajectory generators. It also supports the request and generation of new types of 
trajectory profiles not possible with the previous interface to the Trajectory Synthesizer. 
Other enhancements allow the Trajectory Synthesizer to meet the current and future needs 
of Air Traffic Management research. 


I. Introduction 

T HE Next Generation Air Transportation System (NextGen) project was created by the Joint Planning and 
Development Office (JPDO) to develop future Air Traffic Management (ATM) concepts that will accommodate 
the expected future increase in traffic levels and improve the efficiency of the National Airspace System (NAS). 1 
As a core member of the JPDO, the National Aeronautics and Space Administration (NASA) initiated the Airspace 
Systems Program to research and develop NextGen concepts. Interoperability Research, a research focus area under 
this program, includes the study of methods for computing accurate aircraft trajectory predictions that are 
interoperable with trajectories generated by aircraft flight management systems (FMS). 2 Trajectory prediction 
requires an understanding of the aircraft performance and the constraints (e.g. altitude and speed restrictions) that 
govern the trajectory. NASA proposed the development of a trajectory predictor with the following capabilities 3 : 

• Support variable-order trajectory constraints 

• Describe trajectory constraints which can support interoperability with other trajectory predictors (and 
FMSs) 

• Support air and ground predictions of departure, en-route, and arrival transition segments 

Accurate trajectory predictions are necessary for ATM functions such as conflict prediction, conflict resolution, 
and flight scheduling. Aircraft trajectory predictions are based on information from aircraft performance data, site- 
specific airspace information (e.g., waypoints), weather information, and initial aircraft state conditions and 
constraints (e.g. altitude and speed restrictions). These constraints are used in concert with aircraft equations of 
motion to predict the aircraft’s trajectory. Many trajectory predictors restrict the number or location of constraints 
due to the complexity involved with creating a wide variety of trajectory types. 4 For example, NASA’s Center- 
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TRACON Automation System (CTAS) Trajectory Synthesizer (TS) 5 , which was used to provide predictions for the 
Traffic Management Advisor (TMA) 6,7 modeled only six distinct types of en-route climb and descent profiles. A 
more generalized application of air traffic constraints is needed to support the ATM research involving more 
complex automated and controller assisted aircraft maneuvers 8,9 as well as future trajectory predictor 
interoperability. 

Trajectory predictor interoperability with an aircraft FMS could allow detailed trajectory information to be 
conveyed between an ATM Decision Support Tool (like TMA) and the aircraft. Aircraft intent information could be 
sent from the aircraft to the Decision Support Tool (DST) allowing the DST to obtain more accurate trajectory 
predictions. Conversely, the DST could send the aircraft advisories with details to perform complex aircraft 
maneuvers. 

Interoperability between various trajectory predictors would enable the same set of trajectory constraints to be 
processed by different predictors. Various computation models are used for trajectory predictors that result with 
differences in trajectory accuracy and computation speed. A DST may have specific accuracy and computation 
speed requirements. Interoperability would enable a DST to easily replace the trajectory predictor it uses with one 
that met these requirements. 

The Generalized Trajectory Profile (GenProf) framework was developed to directly address the expression of 
variable-order constraints and trajectory interoperability requirements 2 * . The GenProf framework offers a systematic 
methodology for specifying and calculating trajectories with multiple spatially- separated interdependent constraints. 
GenProf separates the equations of motion from the constraint dependencies by providing a scripting language that 
specifies the trajectory constraints independent of the method for calculating the path between the constraints. The 
GenProf framework was successfully applied to describe the vertical and speed constraints for the CTAS TS, 
supporting the more demanding research requirements of the NextGen Airspace Program. 9,10,11 

This paper describes the development and testing of the new GenProf interface and associated modifications. 
The limitations of the previous Baseline TS that served as the motivation for this new interface, and the capabilities 
of the new GenProf interface are discussed. Finally, the resultant trajectories that can be modeled by the Baseline 
and GenProf TS are compared. 

Since the purpose of the GenProf development was to expand TS capability, the focus of this work was on 
comparing trajectory predictions generated by the Baseline and GenProf TS. The accuracy of the trajectory 
predictions was not compared with actual aircraft track data. The GenProf interface is also applicable to trajectories 
generated for aircraft in the terminal airspace, however, to limit the scope of the paper, the discussion focuses on 
trajectories generated for aircraft in the en-route airspace. 

II. Background 

Trajectory generation capability, provided by the TS, is critical to ATM research at NASA Ames. The TS 
computes 4-D (three physical dimensions and time) aircraft trajectories using equations of motion based on a 
simplified point mass aircraft model 4 . While the basic trajectory generation algorithm has not changed significantly 
over the years, the overall TS software has gone through several enhancements necessary to meet NextGen research 
requirements. 

A. Trajectory Synthesizer Development History 

The first incarnation of the TS was referred to as the Descent Advisor (DA). Written in FORTRAN77 and 
completed in 1984, the DA predictions were used to study the efficacy of controller advisories for fuel-efficient 
descents to the meter fix. 12,13 From a design standpoint, the software was completely integrated; DA handled the 
pilot intent modeling as well as the trajectory generation. Pilot intent modeling describes how the aircraft is 
operated, such as climbing to a specific altitude. The trajectory generator calculates the aircraft’s trajectory based 
upon pilot intent information and models of atmospheric conditions, aircraft performance, and aircraft flight 
dynamics. 

By 1993, DA was integrated with the CTAS program, renamed the Trajectory Synthesizer (hence TS), and re- 
written in the C programming language. 14 At this time, the software was redesigned to split the trajectory engine 
from the routing and intent decision logic. This version of TS was used by NASA and the FAA to develop the TMA 
system, which coupled the predictions at the meter fix (and runway) with a scheduling algorithm to provide 
controllers with delay advisories for arrivals. 15 This version of the TS also supported research by Green and 
Vivona 16 that measured the prediction accuracy of the descent trajectories to the meter fix for a wide variety of test 
conditions. 
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As trajectory generation requirements continued to evolve based on the advanced descent and conflict prediction 
algorithms being researched, 17,18 the TS was rewritten again, this time in C++. This effort resulted in the Baseline TS 
with many of the benefits inherent with Object Oriented design, such as code reuse, code extensibility, and 
improved maintainability. However, it retained much of the older logic that determined the constraints on the 
aircraft trajectories. The Baseline TS uses a set of pre-defined vertical flight profile shapes containing a set of rigid 
constraint combinations. It is, therefore, difficult to add new profiles using the Baseline TS architecture. Given the 
wide range of possible profiles that an aircraft can fly, this is a significant disadvantage to the ATM research 
community. The Baseline TS software is being used by the FAA operational TMA system under Free Flight Phase 
i . 19 

Although the TS software has gone through many design iterations, its core trajectory algorithms have remained 
intact, providing a consistent platform to conduct research and support operational systems. The trajectory engine 
has been repeatedly validated through research, and operationally via the deployed TMA system 16,17,20 . The GenProf 
interface is the next phase of redesign of this software. It builds upon the existing trajectory engine to better support 
anticipated NextGen research requirements. 

B. Design Philosophy of the Trajectory Synthesizer 

Many trajectory generators like the TS use a layered software architecture (Figure 1). In the TS, the top layer is 
the client application such as a DST that formulates the constraints and initial conditions and then sends the 
trajectory request to the trajectory generator (Figure 1). The TS trajectory generator itself has two layers. The first 
one is the behavioral model, which models the pilot or controller intent. The second layer is the math model, which 
consists of the aircraft equations of motion, aircraft performance model data, and control laws. Figure 1 shows a 
diagram illustrating this concept. 

Each of the TS redesign efforts, discussed previously, reevaluated the functional responsibilities of the TS and 
those of the client application. This was trivial with the 1984 DA software where the trajectory engine and client 
functionality were integrated. With each successive TS software iteration, the ideal division of responsibilities 
between the client application and TS became more clearly defined. In their research, Vivona et. al. outline a set of 
rules for any trajectory prediction software to help make these determinations. 21 



L 



Client Application 


Behavioral Model 


Math Model 


Figure 1: General Layered Structure of the TS 


The philosophy behind the current TS enhancement was to make the software architecture flexible. The TS is a 
single codebase that must be agile enough to keep up with the changing research requirements and serve the specific 
requirements of the many client applications such as controller DST concepts being developed. To help ensure that 
different DST functionality does not conflict with each other, the Trajectory Predictor (TP) boundary rule is used. 
The TP Boundary Rule is “...if the capability directly supports a key function of the client application, then the 
capability is considered a client application capability and outside the scope of the TP. ” 21 

Applying the TP Boundary Rule to the design of the TS allows the software to have flexibility it needs to serve 
multiple DSTs. In particular, moving the decision-making process involved in determining the constraints of the 
desired trajectory to the client application, allows the TS to function analogously to a calculator. The TS simply 
receives inputs and provides an output trajectory solution to be used as the client sees fit, without regard to the 
specific motivation behind it. 

This design philosophy also provides a level of transparency for creating the trajectory solution. For example, 
the Baseline TS software contained logic to modify the descent speed and flight path angle of the aircraft to ensure 
that adapted altitude constraints are satisfied. With the new modifications, the TS would make adjustments to the TS 
request without any notification to the client. When implemented, these adjustments supported enhancements to the 
TMA program to support the situation where the altitude and speed of the aircraft at the meter fix is known so a 
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descent to those constraints without regard to other constraints is acceptable. However, the lack of notification 
regarding adjustments to the TS request reduced the usability of the resultant trajectory solutions because other 
clients did not know all of the assumptions used to generate the trajectory. For example, DSTs employing conflict 
detection and conflict resolution are extremely concerned about the aircraft position and time throughout the 
trajectory. Hence, the path of the aircraft is just as important for these clients as the time it reaches a particular fix. 
This highlights the different requirements that DSTs need from the trajectory generator and the need to use the TP 
Boundary Rule in the TS enhancement. 

As mentioned earlier, the Baseline TS adjusted various inputs of the trajectory request such as speeds or flight 
path angles as necessary to compute the trajectory. This is necessary because not every trajectory request will 
initially result with a successful trajectory calculation. Trajectory calculations may fail when the aircraft model 
performance capabilities are exceeded. In the enhanced TS, the code for handling these trajectory failures has been 
moved out of the TS and made into a more flexible organized mechanism. This allows more transparency and 
control by the client application as to how the failure should be addressed. When the client application for the TS 
involves fundamental research it may be better to have the TS fail to help understand why the trajectory request 
constraints could not be satisfied. When the TS is used to support a DST for prototyping and simulation purposes, 
relaxing and adjusting constraints maybe allowed since there is greater emphasis on computing a successful 
trajectory at the cost of loss of accuracy on the constraints. 

The ability to allow expression of trajectory constraints in a flexible manner was a major design goal of the TS 
enhancement. Actual arrival profiles may involve a number of level-offs (down to the meter fix and throughout the 
terminal airspace) or, with the availability of such concepts as Continuous Descent Arrivals, none at all. 22 Figure 2 
shows a descent trajectory with multiple level-offs. Since the TS is primarily used to test these and other ATM 
concepts, it is critical that it be able to model a wide variety of constraints. Hence, the primary design principle of 
the GenProf interface was the decoupling of the vertical constraints from the trajectory engine by providing an 
interface for entering and interpreting the constraints in a form that can be used as input to the trajectory predictor. 
To express the constraints in a flexible manner a scripting language was devised that was intuitive to use. 

Besides flexibility, the GenProf scripting language was designed to be generic. By being generic the language is 
not directly tied to a specific TP and could potentially be used by others. This allows the GenProf language to be a 
medium for interoperability used in expressing vertical constraints between different TPs and clients. Every TP has 
different characteristics that it models and also limitations to its performance and accuracy. Interoperability 
provides the flexibility for client applications using a common interface to swap TPs to meet client requirements. 



Figure 2: An example of a multiple step down trajectory that can be modeled using GenProf versus a single 
step trajectory model limitation by the older version of TS interface 


III. Generalized Profile Interface 

An aircraft trajectory is generated using its initial condition and trajectory constraints. The most basic elements 
of the aircraft’s initial condition are weight, latitude-longitude position, altitude, heading, and speed (ground speed, 
calibrated airspeed, true airspeed, or Mach number). Radar track data is used to supply the TS with the aircraft’s 
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initial latitude- longitude position, altitude, heading, and ground speed. In the case of the TS, the aircraft weight is 
obtained from a database of aircraft models. Airspeeds are determined by using the ground speed and weather data. 

The constraints are the various conditions that must be attained for the trajectory to be successful. For a 
trajectory prediction, these constraints are usually determined using the aircraft’s flight plan. For a trajectory 
advisory, the constraints are determined from a conflict resolution related to a conflict prediction. Constraints are 
categorized as being related to either the vertical or horizontal portion of the trajectory. The constraints for the 
horizontal portion of the trajectory are the list of waypoints that the aircraft uses to define its horizontal flight path, 
i.e. the aircraft’s ground track. From this flight path, a single path distance can be determined. Points along this 
path are used to bind the latitude- longitude position with the vertical position of the trajectory. The software to 
generate the horizontal portion of the flight path is common to both the Baseline TS and the new GenProf TS. 
Details of the horizontal flight path calculation are provided by Erzberger and Lee 4 as well as Slattery and Zhao 5 . 

The GenProf Trajectory Interface allows the user to express a set of vertical constraints that is used by TS 
integrator function. It uses a scripting language to describe the vertical constraint inputs. This language provides 
the flexibility to compose any number of constraint combinations. There are three basic GenProf elements: the 
Anchor, the Profile, and the Stop. GenProf incorporates specifies rules of syntax for combining these elements. The 
following section discusses the GenProf scripting language elements and syntax. 

A. GenProf Elements 

The GenProf Anchor holds the state information that typically represents the initial conditions of the aircraft 
trajectory. The GenProf Anchor consists of an altitude, a speed, and a horizontal path distance. The speed can be 
specified as a Mach, CAS, true airspeed, or ground speed. The TS converts among these speeds by interpolating 
atmospheric and wind data from the NO A A RUC model. 23 The horizontal path distance is the length of the ground 
path of the resultant trajectory. It is derived by integrating the straight line and curved segments that comprise the 
route of flight. 

The GenProf Stop element represents the capture condition that terminates the trajectory segment. GenProf can 
be used to specify an arbitrarily complex boolean expression of stopping conditions with any number of AND (D) 
and OR (U) expressions. However, the current Vertical Profile implementation of GenProf limits the expressions 
which can be evaluated to using only OR expressions, each of which captures a specific value for one of the 
following variables: 

• Altitude Capture 

• Time Capture 

• Path Distance Capture 

• Speed Capture (Mach, CAS, TAS, or ground speed). 

The GenProf Profile element is the most complex of the three. It describes how a trajectory segment is built from 
either a GenProf Anchor or Stop to the next Stop element by combining a set of parameters for the aircraft to adhere 
to until a given capture condition (or set of capture conditions described by the GenProf Stop) is met. Currently 
these parameters include the flight path angle, vertical speed, engine throttle setting, and Mach-CAS profile. Setting 
two of these parameters dictates the equations of motion that will be used to compute the trajectory starting from the 
Anchor until the Stop is reached. 

The Mach-CAS profile is the speed schedule that is typically followed by jets when the aircraft climbs or 
descends. During a descent (starting from an altitude where the pilot is initially flying using Mach speed) a pilot 
will initially maintain the Mach speed described by the Mach-CAS profile. While maintaining the Mach speed, the 
CAS increases as the altitude decreases. When the CAS value designated by the Mach-CAS profile is reached, the 
pilot will switch from maintaining the Mach profile speed to the CAS profile speed. A climb would use the reverse 
of this procedure. Obviously the Mach-CAS profile is applicable to a segment with an altitude change and does not 
apply to a cruise trajectory segment. Currently the Mach-CAS profile must be set as one of the two parameters for 
the Profile. In the future the GenProf Profile will remove this requirement and allow any combination of two 
parameters to be specified. 

B. GenProf Syntax 

The simplest GenProf expression describes a single trajectory segment. This consists of three elements, an 
Anchor, followed by a Profile, which in turn is followed by a Stop. For example, for an aircraft flying at a cruising 
altitude of 33,000 ft and holding a speed of Mach 0.8 for 20 minutes, the GenProf expression is: 
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Anchor 

Profile 

Stop 

33K ft Altitude 
Mach 0.8 

Mach 0.8 

0° Fixed Flight Path Angle 

20min 


Table 1: A Simple GenProf Expression 


The scripting language allows for more Profile- Stop pairs to be chained together, extending the vertical profile as 
necessary and allowing complicated vertical profile expressions to be created. For example, if the previous example 
is expanded to include an additional GenProf Profile having a Fixed Idle Engine Control descent to 18,000 ft using a 
Mach-CAS Profile of Mach 0.8 / 280 knot CAS, the following GenProf expression is used (with the added profile 
described as Profile #2 and Stop #2 respectively): 


Anchor 

Profile #1 

Stop #1 

Profile #2 

Stop #2 

33K ft Altitude 
Mach 0.8 

Mach 0.8; 

0° Fixed Flight Path Angle 

20min 

Mach 0.8/ 280 knot CAS; 
Fixed Idle Engine Control 

18K ft Altitude 


Table 2: A Simple GenProf Expression Appended with an Additional Descent Segment 


This GenProf expression results in a Cruise-Decent vertical profile. When the first segment of this GenProf 
expression (the Anchor, Profile #1, Stop #1) is solved, the capture conditions of Stop #1 are achieved, and the 
remaining aircraft state variables are calculated. At this point Stop #1 has the complete aircraft state information 
and has become equivalent to an Anchor. This new Anchor is used to solve the next trajectory segment described by 
Profile#2 and Stop #2. This procedure is repeated for any additional Profile-Stop pairs. Figure 3 is a notional 
diagram showing the GenProf Expression used in Table 2. 


Anchor Profile #1 Stop 



Figure 3: Graphical Representation of the GenProf Expression used in Table 2 


IV. Generalized Profile Interface Implementation 

For the most part, the underlying trajectory integration functionality is the same for GenProf as it is for the 
previous Baseline TS. GenProf can describe the same trajectory constraints as the previous version of the TS but 
has capability to describe more. The GenProf version of the TS has evolved into an architecture containing more 
smaller separate software modules than the Baseline TS. This allows for easier replacement and modification of 
functionality and, therefore, has the flexibility needed to accommodate the requirements of the different DSTs. 

The GenProf implementation is still under development. GenProf uses the Extensible Markup Language (XML) 
data format to allow data elements to be easily added to the GenProf scripting language. The following section will 
describe the TS Input in more detail and then discuss the TS processing flow. 
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A. TS Input 

The TS Input data structure is the vehicle used to relay the client application’s trajectory request to the TS. The 
XML data format for the input was chosen to provide for potential interoperability with other Trajectory Predictors 
(TPs) other than the TS. The XML data format is a self-describing data format allowing it to be a suitable format for 
data interchange. Another benefit to the XML data format is that it is also easily recognizable text allowing users to 
quickly examine or edit the input. One disadvantage, however, is that the data format can be very verbose and, 
therefore, occupy a large amount of disk space. A sample of the GenProf XML input for the expression in Table 1 
is shown in Figure 4. 


O 

sz 

o 

c 

< 


0 

o 

CL 


Q. 

O 


CO 


<GenAlt Element Type=" ANCHOR" ld="0"> 
<PathDistance>0</PathDistance> 

<CurvedLine> f alse< /CurvedLine> 

<Altitude>33000< /Altitude> 

<Speed Type="MACH_SPEED_TYPE "> 0 . 80</Speed> 

\ < /GenAltElement> 

^<GenAltElement Type=" PROFILE" Id="l"> 

<Mach Type="USE_VALUE"> 0 . 80</Mach> 

<Cas Type="USE_VALUE">- 999999 . 0</ Cas> 
<FixedParameter Type="FIXED_FPA"> 0< /FixedParameter> 
< /GenAltElement> 

t > <GenAltElement Type="STOP" Id="2"> 

<Capture Type=" DELTA TIME_TYPE">20</Capture> 

< IsForwardIntegration> true< /IsForwardIntegration> 
\ < /GenAltElement> 


Figure 4: GenProf XML Input for a Cruise Trajectory 


B. TS Input Processing 

The current implementation of the processing flow for the TS takes the client data inputs to the Baseline TS and 
then translates them into a set of GenProf inputs. A TS Input request will contain both a Baseline set of inputs and a 
GenProf set. This was done in order to compare the results generated by the two different methods. The Baseline to 
GenProf translation process will eventually be removed allowing a direct flow from the client to the GenProf 
interface. 

After the translation process, the constraints are analyzed and the Horizontal profile is processed. Then 
depending on the Vertical Profile processing mode, GenProf or Baseline Vertical Profiles are processed. The final 
step is the trajectory integration process. A diagram of this process flow is shown in Figure 5. 


V. Comparisons with the Baseline TS 

The Baseline TS generates six well defined vertical profiles: Ascent Cruise, Descent Cruise, Ascent Cruise 
Descent, Transition Altitude Descent, Transition Altitude Ascent, and Level Flight (See Figure 6). These were the 
only vertical profiles that could be created. This limitation was one of the primary forces driving the design and 
development of the GenProf interface. Additional features of the GenProf elements were added to allow flexibility 
in describing the climb and descent transitions. The Baseline TS and the GenProf TS were compared to ensure that 
GenProf is able to continue to produce the existing set of trajectories, while allowing for new types of trajectory 
profiles. For any given trajectory request, however, a successful trajectory from both the Baseline TS and GenProf 
TS does not necessarily mean that the two trajectories are identical. The remainder of this section describes the 
comparisons and explains these differences. 
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Figure 5: TS Input Processing Flow 
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A. Number of Trajectory Request Successes 

Table 1 shows the comparison of the number of trajectory requests for the GenProf and Baseline TS using four- 
hours of aircraft traffic data in Fort Worth Center (DFW). In order to provide developers with a simple measure of 
trajectories generated by the two TS versions, the CTAS software was modified to calculate simple trajectory 
comparison statistics. For a given flight, a trajectory calculation is made during each specified time interval as the 
aircraft advances. Therefore, in many cases, a single problematic flight may be the cause of a number of trajectory 
calculation failures. For each trajectory request, the software generated a Baseline trajectory calculation and a 
GenProf trajectory calculation. Total trajectory requests by the client application, successful trajectories and the 
total number of TS trajectory calculations were tallied. 

The number of client requests differs from the number of total TS calculation because the initial TS calculation 
may fail and the TS may handle the failure by recalculating a trajectory with modified constraints. Another statistic 
to note is the large difference of total TS trajectories calculations that GenProf TS has in comparison to Baseline TS. 
This is due to the greater number of trajectory calculation failure cases that GenProf can handle and the multiple 
iterations of trajectory recalculations used to handle the failure cases. Lastly, as seen in Table 3 the percentage of 
successful trajectories is about the same if not slightly better with the GenProf TS than the Baseline TS. 


Trajectory Interface 
Type 

Total Client Trajectory 
Requests 

Successful Client 
Trajectory Requests 

Total TS Trajectory 
Calculations 

Baseline TS 

610394 

97.40% 

611752 

GenProf TS 

609770 

98.44% 

743528 


Table 3: Baseline TS and GenProf TS Total and Successful Trajectory Requests 


B. Vertical Profile Comparison 

The next analysis compared the resultant trajectories generated from GenProf TS with those from the Baseline 
TS. This analysis identified causes of the difference between equivalent Baseline TS and GenProf TS trajectories. 
The trajectories from the GenProf TS and Baseline TS were compared against each other using four-hours of aircraft 
traffic data in Fort Worth Center (DFW) using a simple set of metrics. Based on fixed time intervals and later, fixed 
path distance intervals, points of the trajectories were compared. Table 4 shows the metrics and tolerances that were 
used for the points in the comparison. 


Metric 

Tolerance 

Horizontal Distance 

0.01 nautical miles 

Altitude 

10 feet 

True Air Course 

1 degree 

Ground Course 

1 degree 

True Airspeed 

2 knots 

Calibrated Airspeed 

2 knots 

Ground Speed 

2 knots 

Mach 

0.005 


Table 4: Metrics and Tolerances for Trajectory Comparison 


A simple algorithm was used to determine the vertical profile shape for this analysis to allow for categorizing the 
shapes and more meaningful comparisons. This algorithm compared two consecutive altitudes while stepping 
through the trajectory to determine if there was an altitude change and classified them as an ascent, descent, or 
cruise segment. No threshold of time or distance was used to determine the type of altitude change (ascent, descent, 
cruise) segment. Therefore even a very small series of points with a consistent altitude would be identified as a 
cruise segment. The resulting altitude segment types were then sequentially chained together to produce a vertical 
profile shape. 

The complete results of these trajectory comparisons are shown in Table 5. The total number of trajectories is 
shown along with the number of trajectories found that were different for each Baseline TS profile shape category. 
These various profile shapes are diagramed in Figure 6. A GenProf trajectory was considered different if any of the 
comparison metrics did not meet the specified tolerance when compared against the equivalent Baseline trajectory. 
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The column with the heading of “Different Trajectories with Matching Profile Shape” is used to tally how many 
trajectories have matching profile shapes. A matching profile shape is one where the sequence of altitude profiles 
(ex. Cruise-Descent-Cruise) was the same. Differences between the two systems are not unexpected due to the 
process that translates Baseline TS input into GenProf input (see Figure 5). 

Overall, a large number of GenProf trajectories do not match those generated from the Baseline TS. This is not 
surprising as the comparison tolerances were fairly tight. Also, numerous modifications to the code have been made 
and in many cases the differences are intended. The differences between the Baseline trajectories and GenProf 
trajectories do not necessarily imply that the GenProf trajectories are “wrong”, but possibly just different. The 
differences were investigated further to determine if there were any unexpected differences, and if so, the type and 
amount of discrepancies. The following sections highlight a portion of the results shown in Table 5. 


Baseline Vertical 
Profile Shape 

Total 

Trajectories 

Different 

Trajectories 

Different Trajectories 
With Matching Profile 
Shape 

Overall 

32611 

22514 

- 

Ascent Cruise 

6161 

6161 

16 

Descent Cruise 

1246 

1190 

835 

Cruise Descent 

1638 

1312 

847 

Cruise Descent + 
Cruise 

6793 

5943 

3986 

Ascent Cruise 
Descent (Cruise) 

1505 

1505 

745 

Transition Altitude 
Descent 

284 

272 

161 

Transition Altitude 
Ascent 

2 

2 

0 

Cruise 

12271 

3446 

3438 

Transition Altitude 
Descent + Cruise 

1316 

1311 

416 


Table 5: Comparison of Baseline TS Trajectories to GenProf TS Trajectories 

1. Baseline Ascent Cruise 

None of the GenProf trajectories matched the Baseline Ascent Cruise case (Figure 6a). Out of the 6161 
trajectories, the GenProf TS models 44.4% of these as Ascent-Cruise-Descents and 44.1% as Cruise-Ascent-Cruise- 
Descents. Profile shapes having a Cruise segment appended to ends of the two profile shapes just mentioned, made 
up the remaining differences that GenProf modeled for this case. The reason for these differences between Baseline 
and GenProf TS is because the Baseline Ascent Cruise cases were practically all departures. In the early days of 
CTAS, computation power was limited. Since these trajectories would descend outside the Center of focus and did 
not need to be analyzed outside the Center, the descent segment of these trajectories was disregarded in the Baseline 
TS, to conserve computation power. For these particular trajectory predictions the resultant shape for the Baseline 
TS was an Ascent Cruise instead of an Ascent-Cruise-Descent, which was generated by the GenProf TS. 

2. Baseline Descent Cruise 

The Cruise Descent, and the Cruise Descent + Cruise profile shape cases are all derivatives of the Baseline 
Descent Cruise profile shape (Figure 6b). The additional Cruise segments in the beginning of the trajectory were 
typically constant altitude speed changes to the assigned descent speeds. Cruise segments at the end of the trajectory 
may simply be where the aircraft has reached its final altitude and is cruising at a constant speed or making a final 
speed change. 

Inspecting a small sample of “Different Trajectories With Matching Profile Shape” cases for the Baseline Cruise 
Descent + Cruise profile shape category, show in most instances, only altitude was the differing metric and that the 
maximum altitude delta was 23.1 feet. This indicated that the tolerance was too tight for the altitude comparison. 
Re-running the comparison test and setting the altitude tolerance to 50 feet instead of 10 feet, resulted with Baseline 
TS Cruise Descent + Cruise profile shape category having the number of “Different Trajectories” being reduced by 
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31.3% and the number of “Different Trajectories With Matching Profile Shape” falling by 46.2%. The change in 
altitude tolerance generally only affected the descent cases and the overall number of comparison failures was 
reduced by 10.3%. Further analysis is needed to determine the causes of the remaining discrepancies. 

3. Baseline Cruise 

The next case that was examined is the Baseline Cruise (Figure 6e). Virtually all the cases that had differences 
had the same profile shape. This is not surprising considering the simplicity of the profile. These discrepancies 
were found to be due to variations in the cruise speeds that were used. 


VI. Enhanced Trajectory Modeling Capability 

Ensuring that the GenProf TS can generate the same trajectories as the older Baseline TS is one goal of this 
project. However, the main goal of this effort was to expand the types of trajectories that the TS can model beyond 
the limits the Baseline TS. Currently the client application cannot take full advantage of the flexibility that the 
GenProf TS offers. The Baseline TS to GenProf TS translation process (described in Figure 5) restricts the client to 
the limits of the Baseline TS expressions. A standalone TS application that reads the TS Input data directly is used 
to generate GenProf trajectories without any restriction. Figure 7 is an example of a Multiple Step Climb, Cruise, 
Step Descent trajectory that the GenProf TS is able to generate. The plot illustrates how multiple altitudes and 
speeds can be specified for the trajectory. This trajectory cannot be produced with the Baseline TS since it is 
restricted to the vertical profile shapes shown in Figure 6. 
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Figure 7: Multiple Step Climb, Cruise, Step Descent Trajectory Generated by GenProf 
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VII. Conclusion 

A new interface to the Trajectory Synthesizer (TS) that expresses trajectory constraints in a flexible and 
extensible manner was developed to enhance NextGen research capability at NASA. This new GenProf interface 
allows an almost unlimited number of different trajectory profile types to be described, providing more realistic 
trajectories, and greatly enhancing its utility to NextGen researchers. Furthermore, the interoperability aspect of 
GenProf may increase the scope of its usage outside that of the TS. 

Architectural changes to the software moved much of the decision control logic out of the legacy Baseline TS 
software to client applications, allowing the client process to be able to interpret the trajectory results and make 
adjustments to the trajectory request and resubmit the request, if necessary. The trajectory computation was isolated 
to the TS. Other new capabilities added to the TS improved its maintainability and provides the flexibility needed to 
meet the requirements of various client tools (such as trajectory accuracy and computation performance) that utilize 
the TS. 

Trajectory predictions from the Baseline TS and GenProf versions were compared and the results, in terms of 
the number of successful trajectory requests as well as a comparison of the output trajectories, was analyzed. The 
test that compared the number of successful trajectory requests showed that GenProf TS was able to produce 
approximately the same percentage of successful trajectories as Baseline TS. Comparing equivalent output 
trajectories generated by the Baseline TS against those of the GenProf TS showed that there were a large number of 
differences. A number of differences appear to be related to differences in assigned speeds. Other speed related 
issues such as the point at which the speeds are captured are another source of difference. These can either be 
different points in the flight segment (i.e. beginning or end of a segment) or whether the speed is being captured 
during an altitude change or not. Altitude related differences were evident when examining the Descent Cruise 
profiles cases. Factors involved with these differences were the altitude tolerances used in comparing the 
trajectories. Lastly, in the case of the Climb-Cruise-Descent trajectories, the difference was because the Baseline TS 
ignored the descent portion of the trajectory. These results will be examined further in future analysis. 
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